Systems and methods to enable payments in the absence of a point of sale device

ABSTRACT

A method and system for processing a transaction between a merchant and a consumer using a consumer mobile device wherein the consumer mobile device is in communication with a payment processing computing device having a memory are provided. The method includes receiving merchant data associated with the merchant, receiving a consumer alias associated with the consumer, receiving, a transaction request message from the consumer mobile device, the transaction request message including a merchant identifier, a transaction amount, a device identifier associated with the consumer mobile device, and consumer verification data, retrieving the account number based on the device identifier and the consumer verification data, retrieving the merchant data based on the merchant identifier, generating an authorization request message including the account number, the transaction amount, and the merchant data, and transmitting the authorization request message over a payment network to an issuer bank.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of the filing dateof U.S. Provisional Application No. 61/859,401 filed on Jul. 29, 2013,which is hereby incorporated by reference in its entirety.

BACKGROUND

This disclosure relates generally to consumer initiated financialtransaction payment requests and, more particularly, to computer systemsand computer-based methods for capturing data by a mobile device andprocessing the data for completing a purchase without a point of saledevice.

At least some known merchants engaged in commerce do not use orotherwise have access to traditional point-of-sale (POS) devices.However, customers of these merchants may be inclined to use non-cashoptions when making purchases. For example, merchants may gather atimpromptu locations such as, but, not limited to farmers' markets, fleamarkets, rummage sales, stalls, and kiosks, but may not have access toelectricity, Internet, or to other networks, and resources.

Accordingly, it would be desirable to provide a system and/or method fora consumer-initiated financial transaction without a POS device.

BRIEF DESCRIPTION

In one embodiment, a computer-implemented method for processing atransaction between a merchant and a consumer using a consumer mobiledevice wherein the consumer mobile device is in communication with apayment processing computing device having a memory and wherein themethod includes receiving merchant data associated with the merchant atthe payment processing computing device, receiving a consumer aliasassociated with payment credentials of the consumer at the paymentprocessing computing device, receiving, by the payment processingcomputing device, a transaction request message from the consumer mobiledevice, the transaction request message including a merchant identifier,a transaction amount, a device identifier associated with the consumermobile device, and consumer verification data, retrieving, from thememory, the account number based on the device identifier and theconsumer verification data, retrieving, from the memory, the merchantand associated acquirer bank data based on the merchant identifier,generating, by the payment processing computing device, an authorizationrequest message including the account number, the transaction amount,and the merchant data, transmitting the authorization request messageover a payment network to an issuer bank.

In another embodiment, a computer-implemented method for processing atransaction between a consumer and a merchant using a consumer mobiledevice where the consumer mobile device is in communication with apayment processing computing device having a memory and wherein themethod includes acquiring a price for a transaction between the consumerand the merchant using the consumer mobile device, acquiring merchantdata associated with the merchant using the consumer mobile device,transmitting a device identifier associated with the consumer mobiledevice, the acquired price, and the merchant data in a transactionrequest message to the payment processing computing device, andreceiving, by the consumer mobile device, a transaction authorizationmessage from an issuer bank through a payment network, the transactionauthorization message including an indication of approval or denial ofthe transaction request message.

In yet another embodiment, a mobile remote payment system for processinga transaction between a consumer and a merchant without using a point ofsale (POS) device includes a payment processing computing devicecommunicatively coupled to an electronic communications network, saidpayment processing computing device comprising a processorcommunicatively coupled to a memory device, a consumer mobile devicecomprising an image capture component and a geolocation component, saidconsumer mobile device communicatively couplable to the paymentprocessing computing device through the electronic communicationsnetwork, and a merchant consumer mobile device communicatively couplableto the payment processing computing device through the electroniccommunications network, where the payment processing computing device isprogrammed to receive merchant data associated with the merchant at thepayment processing computing device, receive a consumer alias associatedwith the consumer at the payment processing computing device, receive,by the payment processing computing device, a transaction requestmessage from the consumer mobile device, the transaction request messageincluding a merchant identifier, a transaction amount, a deviceidentifier associated with the consumer mobile device, and consumerverification data, retrieve, from the memory, the account number basedon the device identifier and the consumer verification data, retrieve,from the memory, the merchant data based on the merchant identifier,generate, by the payment processing computing device, an authorizationrequest message including the account number, the transaction amount,and the merchant and acquirer data, and transmit the authorizationrequest message over a payment network to an issuer bank.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-6 show example embodiments of the methods and systems describedherein.

FIG. 1A is a schematic diagram illustrating an example multi-partytransaction card industry system for enabling ordinary payment-by-cardtransactions in which merchants and card issuers do not need to have aone-to-one special relationship.

FIG. 1B is a schematic diagram illustrating another example multi-partypayment card industry system using a mobile remote payment subsystem forenabling payment by mobile device transactions in which merchants andcard issuers do not necessarily have a one-to-one relationship andmerchants do not have a point-of-sale (POS) device.

FIG. 2 is a simplified block diagram of an example processing systemincluding a plurality of computer devices in accordance with oneembodiment of the present disclosure.

FIG. 3 is an expanded block diagram of an example embodiment of a serverarchitecture of a processing system including other computer devices inaccordance with one embodiment of the present disclosure.

FIG. 4 illustrates an example configuration of a user system operated bya user, such as the cardholder shown in FIG. 1.

FIG. 5 illustrates an example configuration of a server system such asserver system shown in FIGS. 2 and 3.

FIG. 6 illustrates a component view of the mobile remote payment systemillustrated in FIG. 2.

DETAILED DESCRIPTION

Embodiments of the methods and systems described herein relate topermitting financial transactions using an interchange network ininstances where the merchant may not have access to a POS device. Such atransaction may be consumer-initiated in that the consumer acquires dataabout the transaction with a portable mobile device, such as, a featurephone, smartphone, or tablet and then generates and transmits anauthorization request to the interchange network.

The methods and systems described herein may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof,wherein the technical effect may include at least one of: (a) receivingmerchant data associated with the merchant at the payment processingcomputing device, (b) receiving a consumer alias associated with paymentcredentials of the consumer at the payment processing computing device,(c) receiving, by the payment processing computing device, a transactionrequest message from the consumer mobile device, the transaction requestmessage including a merchant identifier, a transaction amount, a deviceidentifier associated with the consumer mobile device, and consumerverification data (d) retrieving, from the memory, the account numberbased on the device identifier and the consumer verification data, (e)retrieving, from the memory, the merchant data based on the merchantidentifier, (f) generating, by the payment processing computing device,an authorization request message including the account number, thetransaction amount, the merchant data, and information identifying anacquirer bank associated with the merchant, and (g) transmitting theauthorization request message to the acquirer bank and over a paymentnetwork to an issuer bank.

As used herein, the terms “transaction card,” “financial transactioncard,” and “payment card” refer to any suitable transaction card, suchas a credit card, a debit card, a prepaid card, a charge card, amembership card, a promotional card, a frequent flyer card, anidentification card, a prepaid card, a gift card, and/or any otherdevice that may hold payment account information, such as mobile phones,smartphones, personal digital assistants (PDAs), key fobs, and/orcomputers. Each type of transactions card can be used as a method ofpayment for performing a transaction.

In one embodiment, a computer program is provided, and the program isembodied on a computer readable medium. In an example embodiment, thesystem is executed on a single computer system, without requiring aconnection to a sever computer. In a further example embodiment, thesystem is being run in a Windows® environment (Windows is a registeredtrademark of Microsoft Corporation, Redmond, Wash.). In yet anotherembodiment, the system is run on a mainframe environment and a UNIX®server environment (UNIX is a registered trademark of AT&T located inNew York, New York). The application is flexible and designed to run invarious different environments without compromising any majorfunctionality. In some embodiments, the system includes multiplecomponents distributed among a plurality of computing devices. One ormore components may be in the form of computer-executable instructionsembodied in a computer-readable medium. The systems and processes arenot limited to the specific embodiments described herein. In addition,components of each system and each process can be practiced independentand separate from other components and processes described herein. Eachcomponent and process can also be used in combination with otherassembly packages and processes.

The following detailed description illustrates embodiments of thedisclosure by way of example and not by way of limitation. It iscontemplated that the disclosure has general application to processingfinancial transaction data by a third party in industrial, commercial,and residential applications.

As used herein, an element or step recited in the singular and proceededwith the word “a” or “an” should be understood as not excluding pluralelements or steps, unless such exclusion is explicitly recited.Furthermore, references to “example embodiment” or “one embodiment” ofthe present disclosure are not intended to be interpreted as excludingthe existence of additional embodiments that also incorporate therecited features.

FIG. 1A is a schematic diagram illustrating an example multi-partytransaction card industry system 20 for enabling ordinarypayment-by-card transactions in which merchants 24 and card issuers 30do not need to have a one-to-one special relationship. Embodimentsdescribed herein may relate to a transaction card system, such as apayment card network operated by MasterCard International Incorporated,the assignee of the present disclosure. The payment card network, asdescribed herein, is a four-party payment card interchange network thatincludes a plurality of special purpose processors and data structuresstored in one or more memory devices communicatively coupled to theprocessors, and a set of proprietary communications standardspromulgated by MasterCard International Incorporated for the exchange offinancial transaction data and the settlement of funds between financialinstitutions that are members of the payment network.

In a typical transaction card system, a financial institution called the“issuer” issues a transaction card, such as a credit card, to a consumeror cardholder 22, who uses the transaction card to tender payment for apurchase from a merchant 24. To accept payment with the transactioncard, merchant 24 must normally establish an account with a financialinstitution that is part of the financial payment system. This financialinstitution is usually called the “merchant bank,” the “acquiring bank,”or the “acquirer.” When cardholder 22 tenders payment for a purchasewith a transaction card, merchant 24 requests authorization from amerchant bank 26 for the amount of the purchase. The request may beperformed over the telephone, but is usually performed through the useof a point-of-sale terminal, which reads cardholder's 22 accountinformation from a magnetic stripe, a chip, or embossed characters onthe transaction card and communicates electronically with thetransaction processing computers of merchant bank 26. Alternatively,merchant bank 26 may authorize a third party to perform transactionprocessing on its behalf. In this case, the point-of-sale terminal willbe configured to communicate with the third party. Such a third party isusually called a “merchant processor,” an “acquiring processor,” or a“third party processor.”

Using an interchange network 28, computers of merchant bank 26 ormerchant processor will communicate with computers of an issuer bank 30to determine whether cardholder's 22 account 32 is in good standing andwhether the purchase is covered by cardholder's 22 available creditline. Based on these determinations, the request for authorization willbe declined or accepted. If the request is accepted, an authorizationcode is issued to merchant 24.

When a request for authorization is accepted, the available credit lineof cardholder's 22 account 32 is decreased. Normally, a charge for apayment card transaction is not posted immediately to cardholder's 22account 32 because bankcard associations, such as the payment cardnetwork operated by MasterCard International Incorporated, havepromulgated rules that do not allow merchant 24 to charge, or “capture,”a transaction until goods are shipped or services are delivered.However, with respect to at least some debit card transactions, a chargemay be posted at the time of the transaction. When merchant 24 ships ordelivers the goods or services, merchant 24 captures the transaction by,for example, appropriate data entry procedures on the point-of-saleterminal. This may include bundling of approved transactions daily forstandard retail purchases. If cardholder 22 cancels a transaction beforeit is captured, a “void” is generated. If cardholder 22 returns goodsafter the transaction has been captured, a “credit” is generated.Interchange network 28 and/or issuer bank 30 stores the transaction cardinformation, such as a type of merchant, amount of purchase, date ofpurchase, in a database 120 (shown in FIG. 2).

After a purchase has been made, a clearing process occurs to transferadditional transaction data related to the purchase among the parties tothe transaction, such as merchant bank 26, interchange network 28, andissuer bank 30. More specifically, during and/or after the clearingprocess, additional data, such as a time of purchase, a merchant name, atype of merchant, purchase information, cardholder account information,a type of transaction, itinerary information, information regarding thepurchased item and/or service, and/or other suitable information, isassociated with a transaction and transmitted between parties to thetransaction as transaction data, and may be stored by any of the partiesto the transaction. In the example embodiment, when cardholder 22purchases travel, such as airfare, a hotel stay, and/or a rental car, atleast partial itinerary information is transmitted during the clearanceprocess as transaction data. When interchange network 28 receives theitinerary information, interchange network 28 routes the itineraryinformation to database 120.

After a transaction is authorized and cleared, the transaction issettled among merchant 24, merchant bank 26, and issuer bank 30.Settlement refers to the transfer of financial data or funds amongmerchant's 24 account, merchant bank 26, and issuer bank 30 related tothe transaction. Usually, transactions are captured and accumulated intoa “batch,” which is settled as a group. More specifically, a transactionis typically settled between issuer bank 30 and interchange network 28,and then between interchange network 28 and merchant bank 26, and thenbetween merchant bank 26 and merchant 24.

FIG. 1B is a schematic diagram illustrating another example multi-partypayment card industry system using a mobile remote payment subsystem 34for enabling payment by mobile device transactions in which merchantsand card issuers do not necessarily have a one-to-one relationship andmerchants do not have a point-of-sale (POS) device.

In various regions of the world, merchants may not have POS devices intheir shops or stalls. To facilitate financial transactions in theseregions, an alternate system of charging a customers account, clearingthe transaction, and crediting a merchant's account other messagingalternatives may be implemented.

In the example embodiment, mobile remote payment system 34 includes apayment processing computing device 36 communicatively coupled to anelectronic communications network 38. Payment processing computingdevice 36 includes a processor 40 communicatively coupled to a memorydevice 42. Mobile remote payment system 34 also includes a consumermobile device 44 that includes an image capture component 46 such as,but, not limited to a digital camera, and a geolocation component 48.Consumer mobile device 44 refers to a mobile computing device used by acardholder for making a purchase, transmitting a personal record,storing a personal record, and/or displaying a personal record. Consumermobile device 44 may be embodied in for example, but, not limited to acomputer, smartphone, PDA, tablet, or any other device capable ofperforming the functions described herein. Consumer mobile device 44 maystore payment card information and utilize the stored payment cardinformation to perform payment transactions. Consumer mobile device 44is communicatively couplable to payment processing computing device 36through electronic communications network 38.

Mobile remote payment system 34 includes a merchant mobile device 50communicatively couplable to payment processing computing device 36through electronic communications network 38.

During a transaction, a consumer may wish to purchase a product from amerchant in a shop or stall that does not have a POS device. To initiatea financial transaction for the product, the consumer may scan a priceof the product, either from a tag associated with the product or even ahandwritten price. Alternatively, the price may be entered into aconsumer mobile device 44 using a manual input using a user interface(UI) presented on the consumer mobile device or using speech input. Theconsumer then collects data about the merchant he wishes to do businesswith. In one embodiment, the consumer uses image capture component 46 toacquire an image of the merchant information such as, but, not limitedto a business license or other business identifying information, or anoptically recognizable code such as, but, not limited to a barcode or QRcode that is able to provide the merchant's information that can bedecoded by payment processing computing device 36. Moreover, theconsumer may also use geolocation component 48 to determine ageographical location of the transaction which can be transmitted topayment processing computing device 36 for a determination of themerchant associated with that location. In other embodiments, both imagecapture component 46 and geolocation component 48 can be used togetherto more accurately determine the proper merchant for the transaction.When the information is acquired, the consumer indicates the informationis accurate and consumer mobile device 44 transmits the information inan authorization request message to payment processing computing device36 through network 38. Payment processing computing device 36communicates with interchange 28 for further processing and/orforwarding to issuer 30. Payment processing computing device 36 thenreceives the authorization request response and forwards the response toboth consumer mobile device 44 and merchant mobile device 50.

In various embodiments, payment processing computing device 36 isprogrammed to receive merchant data associated with the merchant,consumer alias, which can be used to obtain an account number associatedwith the consumer at the payment processing computing device, and atransaction request message from consumer mobile device 44, wherein thetransaction request message includes a merchant identifier, atransaction amount, a device identifier associated with consumer mobiledevice 44, and consumer verification data. Rather than using an accountnumber to identify the consumer a consumer alias may be used, such as,but not limited to, a phone number, email address or other identifierrepresentative of the consumer. Payment processing computing device 36is also programmed to retrieve, from memory 42, the consumer accountnumber based on the device identifier, the consumer verification dataand the merchant data based on the merchant identifier. In variousembodiments, the device identifier and the consumer verification dataare passed to interchange 28 where the account number, acquirer data,and merchant data are determined, rather than being determined bypayment processing computing device 36.

Payment processing computing device 36 is further programmed to generatean authorization request message including the account number, thetransaction amount, and the merchant data, transmit the authorizationrequest message over a payment network to an issuer bank, receive anauthorization response message from the issuer bank through the paymentnetwork, and transmit the authorization response message to consumermobile device 44 and merchant mobile device 50.

FIG. 2 is a simplified block diagram of an example processing system 100including a plurality of computer devices in accordance with oneembodiment of the present disclosure. In the example embodiment, system100 may be used for performing payment-by-card transactions and/ormobile remote payments as of part processing the financial transaction.For example, system 100 may receive financial transaction informationfrom mobile remote payment system 34, such as, but, not limited to aprice for a product or service, merchant information, and identifyinginformation for consumer mobile device 44. Some of the information maybe passed on to interchange network 28 for processing or some of theinformation may be processed locally at payment processing computingdevice 36 and the resultant processed data may then be transmitted tointerchange network 28. For example, an image of the price may beacquired by consumer mobile device 44 and the image file may beprocessed using optical character recognition (OCR) onboard consumermobile device 44 to generate a text or other format file containing theprice information. Alternatively, the image file may be transmitted topayment processing computing device 36, where payment processingcomputing device 36 would process the image file to extract the priceinformation. In another embodiment, the image file could be transmittedto interchange network 28, where the price information could beextracted. The processing may be selectable based on the computing powerof the respective devices and/or a bandwidth of the communications linksbetween the components.

More specifically, in the example embodiment, system 100 includes aserver system 112, and a plurality of client sub-systems, also referredto as client systems 114, connected to server system 112. In oneembodiment, client systems 114 are computers including a web browser,such that server system 112 is accessible to client systems 114 usingthe Internet. Client systems 114 are interconnected to the Internetthrough many interfaces including a network, such as a local areanetwork (LAN) or a wide area network (WAN), dial-in-connections, cablemodems, and special high-speed Integrated Services Digital Network(ISDN) lines. Client systems 114 could be any device capable ofinterconnecting to the Internet including a web-based phone, PDA, orother web-based connectable equipment.

System 100 also includes point-of-sale (POS) terminals 118, which may beconnected to client systems 114 and may be connected to server system112. POS terminals 118 are interconnected to the Internet through manyinterfaces including a network, such as a local area network (LAN) or awide area network (WAN), dial-in-connections, cable modems, wirelessmodems, and special high-speed ISDN lines. POS terminals 118 could beany device capable of interconnecting to the Internet and including aninput device capable of reading information from a consumer's financialtransaction card.

A database server 116 is connected to database 120, which containsinformation on a variety of matters, as described below in greaterdetail. In one embodiment, centralized database 120 is stored on serversystem 112 and can be accessed by potential users at one of clientsystems 114 by logging onto server system 112 through one of clientsystems 114. In an alternative embodiment, database 120 is storedremotely from server system 112 and may be non-centralized.

Database 120 may include a single database having separated sections orpartitions or may include multiple databases, each being separate fromeach other. Database 120 may store transaction data generated as part ofsales activities conducted over the processing network including datarelating to merchants, account holders or customers, issuers, acquirers,purchases made. Database 120 may also store account data including atleast one of a cardholder name, a cardholder address, an account number,and other account identifier. Database 120 may also store merchant dataincluding a merchant identifier that identifies each merchant registeredto use the network, and instructions for settling transactions includingmerchant bank account information. Database 120 may also store purchasedata associated with items being purchased by a cardholder from amerchant, and authorization request data. Database 120 may storemerchant and associated acquirer data, an account number and aliasassociated with the consumer, a merchant identifier, a transactionamount, a device identifier associated with the consumer mobile device,and/or consumer verification data for processing according to the methoddescribed in the present disclosure.

In the example embodiment, one of client systems 114 may be associatedwith acquirer bank 26 (shown in FIG. 1) while another one of clientsystems 114 may be associated with issuer bank 30 (shown in FIG. 1). POSterminal 118 may be associated with a participating merchant 24 (shownin FIG. 1) or may be a computer system and/or mobile system used by acardholder making an on-line purchase or payment. Server system 112 maybe associated with interchange network 28. In the example embodiment,server system 112 is associated with a network interchange, such asinterchange network 28, and may be referred to as an interchangecomputer system. Server system 112 may be used for processingtransaction data. In addition, client systems 114 and/or POS 118 mayinclude a computer system associated with at least one of an onlinebank, a bill payment outsourcer, an acquirer bank, an acquirerprocessor, an issuer bank associated with a transaction card, an issuerprocessor, a remote payment system, a biller, and/or mobile remotepayment system 34. Mobile remote payment system 34 may be associatedwith interchange network 28 or with an outside third party in acontractual relationship with interchange network 28. Accordingly, eachparty involved in processing transaction data are associated with acomputer system shown in system 100 such that the parties cancommunicate with one another as described herein.

Using the interchange network, the computers of the merchant bank or themerchant processor will communicate with the computers of the issuerbank to determine whether the consumer's account is in good standing andwhether the purchase is covered by the consumer's available credit line.Based on these determinations, the request for authorization will bedeclined or accepted. If the request is accepted, an authorization codeis issued to the merchant.

When a request for authorization is accepted, the available credit lineof consumer's account is decreased. Normally, a charge is not postedimmediately to a consumer's account because bankcard associations, suchas the payment card network, have promulgated rules that do not allow amerchant to charge, or “capture,” a transaction until goods are shippedor services are delivered. When a merchant ships or delivers the goodsor services, the merchant captures the transaction by, for example,appropriate data entry procedures on the point-of-sale terminal. If aconsumer cancels a transaction before it is captured, a “void” isgenerated. If a consumer returns goods after the transaction has beencaptured, a “credit” is generated.

For debit card transactions, when a request for a PIN authorization isapproved by the issuer, the consumer's account is decreased. Normally, acharge is posted immediately to a consumer's account. The bankcardassociation then transmits the approval to the acquiring processor fordistribution of goods/services, or information or cash in the case of anATM.

After a transaction is captured, the transaction is settled between themerchant, the merchant bank, and the issuer. Settlement refers to thetransfer of financial data or funds between the merchant's account, themerchant bank, and the issuer related to the transaction. Usually,transactions are captured and accumulated into a “batch,” which issettled as a group.

The financial transaction cards or payment cards discussed herein mayinclude credit cards, debit cards, a charge card, a membership card, apromotional card, prepaid cards, and gift cards. These cards can all beused as a method of payment for performing a transaction. As describedherein, the term “financial transaction card” or “payment card” includescards such as credit cards, debit cards, and prepaid cards, but alsoincludes any other devices that may hold payment account information,such as mobile phones, personal digital assistants (PDAs), key fobs, orother devices, etc.

FIG. 3 is an expanded block diagram of an example embodiment of a serverarchitecture of a processing system 122 including other computer devicesin accordance with one embodiment of the present disclosure. Componentsin system 122, identical to components of system 100 (shown in FIG. 2),are identified in FIG. 3 using the same reference numerals as used inFIG. 2. System 122 includes server system 112, client systems 114, andPOS terminals 118. Server system 112 further includes database server116, a transaction server 124, a web server 126, a fax server 128, adirectory server 130, and a mail server 132. A storage device 134 iscoupled to database server 116 and directory server 130. Servers 116,124, 126, 128, 130, and 132 are coupled in a local area network (LAN)136. In addition, a system administrator's workstation 138, a userworkstation 140, and a supervisor's workstation 142 are coupled to LAN136. Alternatively, workstations 138, 140, and 142 are coupled to LAN136 using an Internet link or are connected through an Intranet.

Each workstation, 138, 140, and 142 is a personal computer having a webbrowser. Although the functions performed at the workstations typicallyare illustrated as being performed at respective workstations 138, 140,and 142, such functions can be performed at one of many personalcomputers coupled to LAN 136. Workstations 138, 140, and 142 areillustrated as being associated with separate functions only tofacilitate an understanding of the different types of functions that canbe performed by individuals having access to LAN 136.

Server system 112 is configured to be communicatively coupled to variousindividuals, including employees 144 and to third parties, e.g., accountholders, customers, auditors, developers, consumers, merchants,acquirers, issuers, etc., 146 using an ISP Internet connection 148. Thecommunication in the example embodiment is illustrated as beingperformed using the Internet, however, any other wide area network (WAN)type communication can be utilized in other embodiments, i.e., thesystems and processes are not limited to being practiced using theInternet. In addition, and rather than WAN 150, local area network 136could be used in place of WAN 150.

In the example embodiment, any authorized individual having aworkstation 154 can access system 122. At least one of the clientsystems includes a manager workstation 156 located at a remote location.Workstations 154 and 156 are personal computers having a web browser.Also, workstations 154 and 156 are configured to communicate with serversystem 112. Furthermore, fax server 128 communicates with remotelylocated client systems, including a client system 156 using a telephonelink. Fax server 128 is configured to communicate with other clientsystems 138, 140, and 142 as well.

FIG. 4 illustrates an example configuration of a user system 202operated by a user 201, such as cardholder 22 (shown in FIG. 1). Usersystem 202 may include, but is not limited to, client systems 114, 138,140, and 142, POS terminal 118, workstation 154, and manager workstation156. In the example embodiment, user system 202 includes a processor 205for executing instructions. In some embodiments, executable instructionsare stored in a memory area 210. Processor 205 may include one or moreprocessing units, for example, a multi-core configuration. Memory area210 is any device allowing information such as executable instructionsand/or written works to be stored and retrieved. Memory area 210 mayinclude one or more computer readable media.

User system 202 also includes at least one media output component 215for presenting information to user 201. Media output component 215 isany component capable of conveying information to user 201. In someembodiments, media output component 215 includes an output adapter suchas a video adapter and/or an audio adapter. An output adapter isoperatively coupled to processor 205 and operatively couplable to anoutput device such as a display device, a liquid crystal display (LCD),organic light emitting diode (OLED) display, or “electronic ink”display, or an audio output device, a speaker or headphones.

In some embodiments, user system 202 includes an input device 220 forreceiving input from user 201. Input device 220 may include, forexample, a keyboard, a pointing device, a mouse, a stylus, a touchsensitive panel, a touch pad, a touch screen, a gyroscope, anaccelerometer, a position detector, or an audio input device. A singlecomponent such as a touch screen may function as both an output deviceof media output component 215 and input device 220. User system 202 mayalso include a communication interface 225, which is communicativelycouplable to a remote device such as server system 112. Communicationinterface 225 may include, for example, a wired or wireless networkadapter or a wireless data transceiver for use with a mobile phonenetwork, Global System for Mobile communications (GSM), 3G, or othermobile data network or Worldwide Interoperability for Microwave Access(WIMAX).

Stored in memory area 210 are, for example, computer readableinstructions for providing a user interface to user 201 via media outputcomponent 215 and, optionally, receiving and processing input from inputdevice 220. A user interface may include, among other possibilities, aweb browser and client application. Web browsers enable users, such asuser 201, to display and interact with media and other informationtypically embedded on a web page or a website from server system 112. Aclient application allows user 201 to interact with a server applicationfrom server system 112.

FIG. 5 illustrates an example configuration of a server system 301 suchas server system 112 (shown in FIGS. 2 and 3). Server system 301 mayinclude, but is not limited to, database server 116, transaction server124, web server 126, fax server 128, directory server 130, and mailserver 132.

Server system 301 includes a processor 305 for executing instructions.Instructions may be stored in a memory area 310, for example. Processor305 may include one or more processing units (e.g., in a multi-coreconfiguration) for executing instructions. The instructions may beexecuted within a variety of different operating systems on the serversystem 301, such as UNIX, LINUX, Microsoft Windows®, etc. It should alsobe appreciated that upon initiation of a computer-based method, variousinstructions may be executed during initialization. Some operations maybe required in order to perform one or more processes described herein,while other operations may be more general and/or specific to aparticular programming language (e.g., C, C#, C++, Java, or othersuitable programming languages, etc).

Processor 305 is operatively coupled to a communication interface 315such that server system 301 is capable of communicating with a remotedevice such as a user system or another server system 301. For example,communication interface 315 may receive requests from client system 114via the Internet, as illustrated in FIGS. 2 and 3.

Processor 305 may also be operatively coupled to a storage device 134.Storage device 134 is any computer-operated hardware suitable forstoring and/or retrieving data. In some embodiments, storage device 134is integrated in server system 301. For example, server system 301 mayinclude one or more hard disk drives as storage device 134. In otherembodiments, storage device 134 is external to server system 301 and maybe accessed by a plurality of server systems 301. For example, storagedevice 134 may include multiple storage units such as hard disks orsolid state disks in a redundant array of inexpensive disks (RAID)configuration. Storage device 134 may include a storage area network(SAN) and/or a network attached storage (NAS) system.

In some embodiments, processor 305 is operatively coupled to storagedevice 134 via a storage interface 320. Storage interface 320 is anycomponent capable of providing processor 305 with access to storagedevice 134. Storage interface 320 may include, for example, an AdvancedTechnology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, aSmall Computer System Interface (SCSI) adapter, a RAID controller, a SANadapter, a network adapter, and/or any component providing processor 305with access to storage device 134.

FIG. 6 illustrates a component view 500 of the payment and record system100 as illustrated in FIG. 2. In the example embodiment, Server system112 includes a plurality of components for performing the functionsdescribed herein. More specifically, server system 112 comprises aprocessor 502, a receiver component 504, a transmitter component 506, apayment network interface component 508, a memory interface component510, a verification component 514, an available account component 516,an available personal record component 518, a transaction rewardcomponent 520, and an associated personal record transaction component522.

Processor 502 may be any device capable of executing computer-executableinstructions. Processor 502 may be configured to process and direct datafrom one component to another component. In the example embodiment,processor 502 may be the Central Processing Unit (CPU) of server system112.

Receiver component 504 may be any device capable of receiving a signal.In the example embodiment, receiver component 504 includes a networkadapter for receiving data through a network connection such as a WAN orLAN. Receiver component 504 is communicatively coupled to at least oneof client system 114, payment processing computing device 36, andprocessor 502. Receiver component 504 is configured to receive data frompayment processing computing device 36 and route the data to processor502.

Transmitter component 506 may be any device capable of transmitting asignal. In the example embodiment, transmitter component 506 is anetwork adapter capable of transmitting data through a networkconnection such as a WAN or LAN. Transmitter component 506 iscommunicatively coupled to processor 502 and payment processingcomputing device 36, and is configured to transmit signals fromprocessor 502 to payment processing computing device 36.

Payment network interface component 508 may be any device or set ofcomputer-executable instructions that enables server system 112 tocommunicate with interchange network 28. In the example embodiment,payment network interface component 508 is a network adapter and sendsand receives data through a network connection such as a WAN or LAN.

Memory interface component 510 may be any device or set ofcomputer-executable instructions for communicating with memory 120. Inthe example embodiment, memory interface 510 communicates with memory120 to store and retrieve data.

Verification component 514 may be a device or set of computer-executableinstructions for verifying the identity of at least one of cardholder 22and merchant 24. Verification component 514 may use, for example, apersonal identification number (PIN) entered by cardholder 22 ormerchant 24. Additionally, a challenge question using transaction dataassociated with cardholder 22 may be presented to cardholder 22 andcardholder 22 be prompted for an answer. Because the challenge questionor questions are based on cardholder 22 own transaction data, theprobability that only cardholder 22 would be able to answer thechallenge question(s) is relatively high.

Available account component 516 may be a device or set ofcomputer-executable instructions for determining payment accountsassociated with cardholder 22 that are available for making a paymenttransaction. The available account component 516 may also provide a listof available accounts to cardholder computing device 121.

Available personal record component 518 may be any device or set ofcomputer-executable instructions for determining personal records thatare available to be stored or are available to be transferred. Thepersonal records available to be transferred may be stored in memory120. The personal records to be stored may be located on client system114 or cardholder computing device 121.

Transaction reward component 520 may be a device or set ofcomputer-executable instructions for determining whether any discounts,coupons, rewards points, product reviews, or other incentives, areassociated with a particular payment transaction.

Associated personal record transaction component 522 may be any deviceor set of computer-executable instructions for determining whether anadditional personal record transaction associated with at least one of acompleted payment transaction and a completed personal recordtransaction is available.

As used herein, the terms “software” and “firmware” are interchangeable,and include any computer program stored in memory for execution byprocessors 40, 205, and/or 305. Memory area 310 may include, but are notlimited to, random access memory (RAM) such as dynamic RAM (DRAM) orstatic RAM (SRAM), read-only memory (ROM), erasable programmableread-only memory (EPROM), electrically erasable programmable read-onlymemory (EEPROM), and non-volatile RAM (NVRAM). The above memory typesare examples only, and are thus not limiting as to the types of memoryusable for storage of a computer program.

The term processor, as used herein, refers to central processing units,microprocessors, microcontrollers, reduced instruction set circuits(RISC), application specific integrated circuits (ASIC), logic circuits,and any other circuit or processor capable of executing the functionsdescribed herein.

As will be appreciated based on the foregoing specification, theabove-discussed embodiments of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof. Anysuch resulting program, having computer-readable and/orcomputer-executable instructions, may be embodied or provided within oneor more computer-readable media, thereby making a computer programproduct, i.e., an article of manufacture, according to the discussedembodiments of the disclosure. The computer readable media may be, forinstance, a fixed (hard) drive, diskette, optical disk, magnetic tape,semiconductor memory such as read-only memory (ROM) or flash memory,etc., or any transmitting/receiving medium such as the Internet or othercommunication network or link. The article of manufacture containing thecomputer code may be made and/or used by executing the instructionsdirectly from one medium, by copying the code from one medium to anothermedium, or by transmitting the code over a network.

The above-described embodiments of a method and system of a mobileremote payment system provides a cost-effective and reliable means forreceiving a consumer initiated financial payment request during afinancial transaction with a merchant that may not have a POS device.More specifically, the methods and systems described herein facilitateacquiring the data needed by a consumer to submit a paymentauthorization request message to an interchange network. In addition,the above-described methods and systems facilitate transmitting apayment authorization request message to an issuer bank forauthorization As a result, the methods and systems described hereinfacilitate expanding consumers' ability to engage in commerce in acost-effective and reliable manner.

This written description uses examples to disclose the disclosure,including the best mode, and also to enable any person skilled in theart to practice the disclosure, including making and using any devicesor systems and performing any incorporated methods. The patentable scopeof the invention is defined by the claims, and may include otherexamples that occur to those skilled in the art. Such other examples areintended to be within the scope of the claims if they have structuralelements that do not differ from the literal language of the claims, orif they include equivalent structural elements with insubstantialdifferences from the literal languages of the claims.

1. A computer-implemented method for processing a transaction between amerchant and a consumer using a consumer mobile device, the consumermobile device in communication with a payment processing computingdevice, the payment processing computing device having a memory, saidmethod comprising: receiving merchant data associated with the merchantat the payment processing computing device; receiving a consumer aliasassociated with payment credentials of the consumer at the paymentprocessing computing device; receiving, by the payment processingcomputing device, a transaction request message from the consumer mobiledevice, the transaction request message including a merchant identifier,a transaction amount, a device identifier associated with the consumermobile device, and consumer verification data; retrieving, from thememory, the account number based on at least one of the consumer alias,the device identifier, and the consumer verification data; retrieving,from the memory, the merchant data based on the merchant identifier;generating, by the payment processing computing device, an authorizationrequest message including the account number, the transaction amount,the merchant data, and information identifying an acquirer bank; andtransmitting the authorization request message to an acquirer bankassociated with the merchant and over a payment network through theacquirer bank to an issuer bank.
 2. The computer-implemented method ofclaim 1, further comprising verifying the consumer account informationincluding at least one of a personal identification number (PIN) and achallenge question.
 3. The computer-implemented method of claim 1,wherein receiving a device identifier associated with the consumermobile device comprises receiving a device identifier that is unique tothe consumer mobile device.
 4. The computer-implemented method of claim1, wherein receiving a device identifier associated with the consumermobile device comprises receiving the consumer alias associated with theconsumer mobile device.
 5. The computer-implemented method of claim 1,further comprising transmitting an authorization request response to themerchant as a notification message.
 6. The computer-implemented methodof claim 1, wherein receiving the transaction amount comprises receivingthe transaction amount by the payment processing computing device afterthe consumer enters the transaction amount into the consumer mobiledevice and verifies that the transaction amount is accurate.
 7. Thecomputer-implemented method of claim 1, wherein receiving thetransaction amount comprises receiving the transaction amount by thepayment processing computing device after the transaction amount isentered into the consumer mobile device, wherein the consumer mobiledevice is configured to scan an image of the transaction amount andconvert the image into machine-encoded text.
 8. The computer-implementedmethod of claim 7, further comprising converting, by the consumer mobiledevice, the scanned image using optical character recognition.
 9. Thecomputer-implemented method of claim 1, wherein receiving the merchantidentifier comprises receiving the merchant identifier by the paymentprocessing computing device after the merchant identifier is enteredinto the consumer mobile device.
 10. The computer-implemented method ofclaim 1, wherein receiving the merchant identifier comprises receivingthe merchant identifier by the payment processing computing device afterthe merchant identifier is captured by the consumer mobile device,wherein the merchant identifier is included within at least one of a barcode, and a QR code, and wherein the consumer mobile device isconfigured to read at least one of a bar code, and a QR code.
 11. Thecomputer-implemented method of claim 1, wherein receiving the merchantidentifier comprises receiving the merchant identifier by the paymentprocessing computing device after the merchant identifier is captured bythe consumer mobile device by scanning an image of the merchantidentifier and converting the image into machine-encoded text.
 12. Thecomputer-implemented method of claim 1, wherein receiving the merchantidentifier comprises receiving the merchant identifier by the paymentprocessing computing device after the consumer mobile device determinesthe merchant identifier using geo-location.
 13. A computer-implementedmethod for processing a transaction between a consumer and a merchantusing a consumer mobile device, the consumer mobile device incommunication with a payment processing computing device, the paymentprocessing computing device having a memory, said method comprising:acquiring a price for a transaction between the consumer and themerchant using the consumer mobile device; acquiring merchant dataassociated with the merchant using the consumer mobile device;transmitting a device identifier associated with the consumer mobiledevice, the acquired price, and the merchant data in a transactionrequest message to the payment processing computing device; andreceiving, by the consumer mobile device, a transaction authorizationmessage from an issuer bank through a payment network, the transactionauthorization message including an indication of approval or denial ofthe transaction request message.
 14. The method of claim 13, whereinacquiring merchant data associated with the merchant using the consumermobile device comprises acquiring a geolocation of the merchant usingthe consumer mobile device
 15. The method of claim 13, wherein acquiringa price comprises acquiring an image of the price using the consumermobile device.
 16. The method of claim 13, wherein acquiring merchantdata comprises acquiring at least one of an image of an opticallyrecognizable code encoded with the merchant and a geolocation of themerchant using the consumer mobile device.
 17. The method of claim 13,further comprising transmitting a notification message including anindication of approval or denial of the transaction request message tothe merchant.
 18. A mobile remote payment system for processing atransaction between a consumer and a merchant without using a point ofsale (POS) device, said system comprising: a payment processingcomputing device communicatively coupled to an electronic communicationsnetwork, said payment processing computing device comprising a processorcommunicatively coupled to a memory device; a consumer mobile devicecomprising an image capture component and a geolocation component, saidconsumer mobile device communicatively couplable to the paymentprocessing computing device through the electronic communicationsnetwork; and a merchant mobile device communicatively couplable to thepayment processing computing device through the electroniccommunications network, where the payment processing computing device isprogrammed to: receive merchant data associated with the merchant at thepayment processing computing device; receive a consumer alias associatedwith the consumer at the payment processing computing device; receive,by the payment processing computing device, a transaction requestmessage from the consumer mobile device, the transaction request messageincluding a merchant identifier, a transaction amount, a deviceidentifier associated with the consumer mobile device, and consumerverification data; retrieve, from the memory, the account number basedon the device identifier and the consumer verification data; retrieve,from the memory, the merchant data based on the merchant identifier;generate, by the payment processing computing device, an authorizationrequest message including the account number, the transaction amount,and the merchant data; and transmit the authorization request message toan acquirer bank associated with the merchant and over a payment networkto an issuer bank.
 19. The system of claim 18, wherein the paymentprocessing computing device is programmed to: receive an authorizationresponse message from the issuer bank through the payment network; andtransmit the authorization response message to the consumer mobiledevice and the merchant mobile device.
 20. The system of claim 18,wherein the consumer mobile device and the merchant mobile device arewireless devices communicatively couplable to the payment processingcomputing device through a wireless portion of the electroniccommunications network.
 21. The system of claim 18, wherein the consumermobile device is programmed to acquire an image of merchant data and ageolocation of the merchant.